|
Вязмин Владислав ИвановичФакультет компьютерных наук и технологийКафедра программной инженерииСпециальность
|
При написании данного реферата магистерская работа еще не завершена. Окончательное завершение: июнь 2021 года. Полный текст работы и материалы по теме могут быть получены у автора или у его руководителя после указанной даты.
Введение
Голосовые мессенджеры [1] приобрели свою популярность совсем недавно. Развитие данной отрасли берет своё начало в момент, когда средняя скорость интернета по всему миру стала достаточно комфортной для использования данных приложений даже на смартфонах. Мессенджер – это программа, мобильное приложение или веб-сервис для мгновенного обмена сообщениями, в данном случае, голосовыми. Данная отрасль начала развиваться достаточно бурно и эффективно, что привело к созданию по меньшей мере сотен, а то и тысячи мессенджеров.
Мессенджер представляет собой клиент-серверное приложение [2], которое может быть реализовано для пользователя как мобильное приложение или веб-сервис для мгновенного обмена сообщениями. Это направление развивается достаточно быстро и эффективно, что приводит к созданию по меньшей мере сотен, а то и тысячи мессенджеров разными фирмами-разработчиками программного обеспечения и отдельными программистами по всему миру. Передача голоса с использованием Интернета достаточно сильно распространена в кругах как частных пользователей, так и в государственных и корпоративных учреждениях. Для передачи медиаданных, а в частности аудиоданных по сети между пользователями применяется протокол передачи реального времени RTP [3], который является небезопасным, поскольку по умолчанию он не содержит криптографического шифрования и аутентификации, а данные в RTP-пакете передаются в открытом виде. По этой причине актуальной является задача повышения эффективности протоколов передачи голосовых сообщений.
1. Цели и задачи исследования, планируемые результаты
Целью исследования является определение и устранение уязвимостей в протоколах передачи медиаданных, а также выявление и устранение предполагаемых уязвимостей в механизмах регистрации и аутентификации пользователей при разработке приложений с использованием протоколов для передачи голосовых сообщений с криптографической защитой. Практическая ценность заключается в разработке протокола передачи голосовых сообщений с криптографической защитой, а также модифицированного способа аутентификации пользователя при помощи QR-кода [4] для приложений по передаче голосовых сообщений с криптографической защитой.
Результатом данной магистерской работы будет является разработанный авторский протокол для передачи медиаданных с криптографической защитой, а также модифицированный способ аутентификации пользователя при помощи QR-кода.
2. Анализ проблем передачи мультимедийных данных по сети
Для передачи голосовых сообщений между пользователями необходимо установить соединения. Существуют два основных протокола передачи данных, это UDP [5] и TCP [6]. ТСP является надежным протоколом для передачи данных, ведь доставка гарантируется, однако, для передачи потоковых медиаданных он не подходит, поскольку в данном случае необходима скорость, а TCP будет проверять, отправлен ли пакет, и если нет, тогда заново отправит его. В этом случае на помощь приходит протокол UDP, он обеспечит необходимую скорость, однако он не гарантирует доставки пакета, что означает, что пользователь может не получить сказанное слово, или же получить его не полностью. Следовательно, следующей проблемой является передача данных в полном объеме без потерь.
3. Обзор литературы по проблеме передачи мультимедийных данных по сети
В книге Основы передачи голосовых данных по сетям IP
авторы приводят такой же пример, какой был описан выше, а именно: По передаче голосовых данных по сетям IP протокол ТСР гарантирует надежность установленного соединения. Однако методы,
используемые протоколом ТСР, не позволяют применить его в качестве механизма передачи собственно голосовых данных (RTP). При передаче голосовых данных по сетям IP потеря пакета – это меньшее зло, по сравнению с сетевой задержкой. В настоящее
время протокол Н.323 использует протокол ТСР, а протоколы SIP и MGCP-протокол UDP (в качестве транспортного механизма, протокол SIР способен также использовать протокол ТСР).
При передаче голосовых данных по сетям IP протокол UDP используется для передачи собственно голосового трафика (каналы-носители). Протокол ТСР для этого не используется, потому что в данном случае управление потоком и повторная передача звуковых пакетов попросту не нужны. Поскольку протокол UDP только передает звуковой поток, на его передачу не повлияет ни 5%-ная потеря пакетов, ни 50%-ная.
Если бы для передачи голосовых данных по сетям IP использовался протокол ТСР, сетевая задержка, усиленная ожиданием подтверждений и повторными передачами, серьезно ухудшила бы качество звука. Для передачи голосовых данных по сетям IP и других приложений реального времени контроль сетевой задержки является более важной задачей, чем обеспечение надежной передачи каждого пакета.
С другой стороны, протокол ТСР используется для установления соединения большинством протоколов передачи служебных сигналов при передаче голосовых данных по сетям IP [7].
В книге Компьютерные сети. Нисходящий подход
рассматривается более подробная структура протоколов, большое внимание уделяется протоколам передачи медиаданных [8]. В данной книге как пример приводится работа различных
популярных сервисов, таких как YouTube, Skype и других. Большое внимание уделено одной из развивающихся сегодня областей – мультимедийным сетевым технологиям, в частности, специфике передачи аудио- и видеоданных. Книга рассказывает о
мультимедийных сетях. Теперь в ней можно найти подробное обсуждение потокового видео; в частности, адаптивное потоковое вещание. Кроме того, в книге появился совершенно новый раздел о сетях доставки контента (CDN). Также идет речь о системах
потокового видео Netflix, YouTube и Kankan.
Передача данных, будь то текст или голос и видео, может происходить в реальном или модельном времени. Данные мультимедиа могут быть данными как реального, так и модельного времени. Реальное время – это возможность видеть и слышать данные динамически.
Например, видеоклип, просматриваемый по мере его загрузки на вашу сетевую станцию, классифицируется как приложение реального времени. Камера, снимающая чье-либо выступление совместно с видеосерверами, использующими протокол IР, и распространяющая
полученные данные на тысячи рабочих станций для просмотра в реальном времени – еще один пример. Голос и видео требуют соблюдения специальных условий, а точнее, приложения реального времени предъявляют определенные требования к механизмам
передачи данных, которые рассмотрены в книге TCP/IP. Иллюстрированный учебник
[9].
3.1 Обзор локальных источников
Проблемы защищенности передаваемых данных в мессенджерах были рассмотрены в статье магистра ДонНТУ Крушанова А.И. в рамках II Международной научно-практической конференции ПИИВС–2018, где автор обращает особое внимание на обмен ключами между пользователями и проектирует для этого собственный протокол, что тоже указывает на актуальность проблемы [10].
Ранее, в рамках X Международной научно-технической конференции ИУСМКМ–2019, мною рассматривались существующие протоколы для программной реализации голосовых мессенджеров и после их рассмотрения я пришел к выводу, что разработка голосового мессенджера является достаточно трудоемким процессом, который включает в себя тесную связь различных протоколов [11].
4. Анализ протоколов передачи голосовых сообщений
Каждый голосовой мессенджер так или иначе передает потоковые данные по сети, при этом голос передается при помощи различных транспортных протоколов. Каждый существующий голосовой мессенджер тем или иным образом использует их. Транспортные протоколы, в данном случае, предусмотрены для потоковой передачи медиаданных, а именно – звука. В настоящее время существует два наиболее распространенных протокола для этих целей. Это протоколы RTP и SRTP, которые помогают передавать потоковые данные, однако и у них существуют свои недостатки.
4.1 Анализ протокола RTP
Как правило, для этих целей используется протокол RTP (Real-time Transport Protocol) – транспортный протокол в реальном времени. Именно он обеспечивает передачу данных в реальном времени. Данные RTP обычно доставляются по протоколу UDP, который является ненадежным транспортным протоколом. Следовательно, нет гарантии доставки пакетов на транспортном уровне. Пакеты будут приниматься в том порядке, в котором они были отправлены или пакеты будут отправляться с постоянной скоростью. Порядковые номера пакетов и временные метки позволяют приложению, принимающему пакеты RTP, восстанавливать последовательность пакетов отправителя, обнаруживать изменения в сети и соответствующим образом корректировать. На рисунке 1 представлена схема передачи аудиоданных по сети с использование протокола RTP.
Рисунок 1 – Передача аудиоданных по сети с использованием протокола RTP
Использование протокола UDP для инкапсуляции пакетов RTP включает в себя определенные ограничения, такие как ошибки при передаче. В результате любая потерянная или поврежденная часть просто игнорируется. Протокол RTP служит для передачи звука и изображений, но никак не отслеживает целостность передаваемых данных. RTP не обеспечивает автоматическую повторную передачу пропущенных пакетов. Однако, передавать данные, используя только RTP неразумно с точки зрения безопасности передаваемых данных, поскольку они могут быть перехвачены третьими лицами. Следовательно, все мессенджеры, как правило, шифруют передаваемые данные и большинство мессенджеров для этих целей используют протокол SRTP [12].
Сегодня большая часть трафика VoIP отправляется без какой-либо криптографической защиты [13] и уязвима с точки зрения прослушивания и модификации, поэтому использование средств защиты является актуальной задачей.
4.2 Анализ протокола SRTP
SRTP (Secure Real-time Transport Protocol) представляет собой расширение протокола RTP, которое добавляет дополнительные функции безопасности, такие как аутентификация сообщений, их шифрование, проверка целостности и защита от замены данных, в основном предназначен для VoIP-коммуникаций. SRTP является одним из протоколов безопасности, используемых для технологии WebRTC. Как правило, в SRTP по умолчанию для шифрования используется AES-CM [14]. Основной причиной выбора AES-CM было отсутствие расширения полезной нагрузки (зашифрованная полезная нагрузка имеет ту же длину, что и исходная). Другая особенность AES-CM позволяет обрабатывать пакеты не по порядку, что подразумевает возможность обрабатывать пакеты параллельно. Под полезной нагрузкой подразумевается часть передаваемого пакета, в которой находится фактическое сообщение. Следовательно, можно сделать вывод, что все голосовые мессенджеры для передачи потоковых данных используют протокол RTP, поверх которого используют различные алгоритмы шифрования. Сравнение протокола RTP и SRTP показано на рисунке 2.
Рисунок 2 – Сравнение протокола RTP и SRTP (анимация из 27-ми кадров, 6-ти циклов, размером 77 Кб)
Информация о криптографическом состоянии, связанная с каждым потоком SRTP, называется криптографическим контекстом. Оно (состояние) должно поддерживаться как отправителем, так и получателем. Если в данном сеансе RTP присутствует несколько потоков SRTP, для каждого должен поддерживаться отдельный криптографический контекст (допустим отправляем одновременно звук и видео, но в разных потоках).
Криптографический контекст включает в себя любой сеансовый ключ (ключ непосредственно в шифровании/аутентификации сообщения) и главный ключ (случайная битовая строка, используемая для получения сеансовых ключей), а также другие параметры рабочего сеанса.
Хотя SRTP не определяет точный механизм для реализации обмена ключами, он обеспечивает несколько функций, которые упрощают управление ключами и повышают общую безопасность. Главный ключ используется для предоставления ключевого материала для ключа функции вывода.
Благодаря этому могут генерироваться начальные сеансовые ключи [15], а также, этот механизм периодически предоставляет новые ключи сеанса, чтобы гарантировать ограниченную длину шифротекста, полученного любым заданным ключом шифрования. Сеансовые ключей используются для обеспечения защиты от различных воздействий, таких как предварительное вычисление и атаки с использованием памяти во времени.
Периодическое изменение самой функции генерации ключей ведет к дополнительным мерам по усилению безопасности. Как правило это препятствует тому, чтобы человек посередине собрал большое количество зашифрованного материала, зашифрованного с одним единственным сеансовым ключом. Некоторые взломы легче выполнить, когда имеется большое количество зашифрованного материала. Кроме того, многократное изменение функции генерации ключей обеспечивает прямую и обратную безопасность в том смысле, что расшифрованный сеансовый ключ не ставит под угрозу другие сеансовые ключи, полученные из того же самого главного ключа. Это означает, что, даже если взломщику удалось получить определенный сеансовый ключ, он не в состоянии расшифровать сообщения, обеспеченные с предыдущими и более поздними сеансовыми ключами, полученными из того же самого главного ключа (хотя, конечно, полученный главный ключ даст все сеансовые ключи, полученные из него).
SRTP полагается на внешний протокол обмена ключами, чтобы установить главный начальный ключ. SRTP для этих целей использует такие протоколы как ZRTP [16] и MIKEY [17]. Есть и другие методы, чтобы договориться о ключах SRTP. Несколько различных производителей предлагают продукты, которые используют метод обмена ключей SDES.
5. Модифицированный способ аутентификации пользователя при помощи QR-кода
На момент работы над авторефератом был спроектирован модифицрованный способ аутентификации пользователя при помощи QR-кода для приложений по передаче голосовых сообщений с криптографической защитой [18].
Перед входом в каждую систему пользователю сначала необходимо зарегистрироваться в ней, а затем при каждом входе совершать аутентификацию. Однако, если при аутентификации пользователь будет использовать только свой пароль, то существует риск того, что злоумышленник сможет получить доступ к паролю пользователя. Для обеспечения большей безопасности пользовательских данных было решено дополнить парольную аутентификацию пользователя для программного обеспечения типа мессенджер использованием QR-кода. Предполагается, что клиентское приложение будет использоваться на персональных компьютерах. Аутентификация в данном приложении производится с использованием логина, пароля, QR-кода и электронной почты. Как только пользователь запустит клиентскую часть приложения, будет сгенерирована пара ключей RSA (приватный и публичный ключ) [19], затем, с сервером будет осуществлен обмен публичными ключами. Каждый раз при аутентификации будет осуществляться генерация новых ключей. На стороне сервера пользователь будет идентифицирован как незарегистрированный пользователь, ему будет присвоен свой уникальный идентификатор и пара ключей, сгенерированных алгоритмом RSA для этого пользователя. После обмена открытыми ключами между клиентом и сервером, сами ключи будут занесены в базу данных на стороне сервера, в которой будут храниться данные о всех подключениях в текущий момент времени. Этап запуска пользователем приложения продемонстрирован на рисунке 3.
Рисунок 3 – Действия, происходящие на этапе запуска пользователем приложения
Дальше рассмотрим сценарий, когда пользователь не зарегистрирован в системе, и собирается пройти этап регистрации с последующей работой в приложении. В самом начале, после того как был осуществлен обмен ключами с сервером, пользователь выбрал этап регистрации. Во время регистрации пользователь ввел свой логин, пароль и адрес электронной почты. После этого от пароля пользователя берется хеш, затем все введенные пользователем данные объединяются в одну строку, после чего полученная строка переводится в base64 [20], шифруется помощи приватного RSA ключа пользователя и отправляется на сервер. Сервер в свою очередь, получает эти данные, расшифровывает публичным ключом пользователя, преобразует данные в понятный вид и проверят на достоверность (существует ли пользователь с таким электронным адресом или логином), и в случае, если валидация была пройдена, эти данные заносятся в базу данных. Данная процедура показана на рисунке 4.
Рисунок 4 – Процедура регистрации и аутентификации пользователя
Затем, пользователь решает зайти в систему как зарегистрированный пользователь. После того, как пользователь ввел свои данные, и они прошли проверку на сервере (верный пароль от аккаунта), сервер отвечает на это, и затем клиентская часть приложения просит ввести QR-код, который был сгенерирован сервером и отправлен по электронной почте пользователю. После чего пользователь заходит в свою электронную почту, загружает высланный сервером QR-код, вставляет его в нужное поле в клиентской части, где этот QR-код расшифровывается, получается строка в base64, затем шифруется алгоритмом RSA и отправляется на сервер для сверки. Если все пройдет успешно, то пользователь может работать с клиентской частью программной системы. Ориентировочная схема представлена на рисунке 5.
Рисунок 5 – Двухфакторная аутентификация пользователя
Предложенный алгоритм генерации QR-кода на серверной части приложения показан на рисунке 6.
Рисунок 6 – Генерация QR-кода на серверной части приложения
Выводы
В ходе исследования было выявлено, что для потоковой передачи данных в большинстве известных мессенджеров служит протокол RTP. Для обеспечения защиты передаваемой информации поверх протокола RTP используются известные криптографические алгоритмы шифрования. Результатом написания магистерской диссертации будут являться разработанные протоколы которые теоретически смогут прийти на замену SRTP и стандартным методам аутентификации. В ходе анализа существующих протоколов было выявлено, что протоколы передачи аудиоданных достаточно сильно подвержены к прослушиванию и подмене трафика.
Дальнейшие исследования по этой теме будут направлены на следующие аспекты:
Список источников
Э, 2016. – 912 с.
Crypto Messenger/ А.И. Крушанов, А.В. Чернышова // Программная инженерия: методы и технологии разработки информационно-вычислительных систем (ПИИВС–2018): сборник научных трудов II научно-практической конференции (студенческая секция), том 2 / Донец.национал.техн.ун-т; — Донецк, 2017. — С. 116-120.
